✅ With the latest revision this PR passed the C/C++ code formatter.

I like the overall direction, thanks for taking the time to improve the holistic approach. One nit is to perhaps rename ClangAdddressSpaceAttr to LangAdddressSpaceAttr. Let's see if other reviewers have more insight here.

(cc @koparasy)

I like the overall direction, thanks for taking the time to improve the holistic approach. One nit is to perhaps rename ClangAdddressSpaceAttr to LangAdddressSpaceAttr. Let's see if other reviewers have more insight here.

(cc @koparasy)

I don’t have a strong objection to the implementation itself — the patch is clear and seems consistent with the upstream direction. My only hesitation is around the conceptual cost of introducing two separate address-space attributes. Address spaces are already a tricky area, and users can also influence them via language-level attributes, so reasoning about them tends to get complicated quickly.

Do we have a long-term plan for how TargetAddressSpaceAttr and ClangAddressSpaceAttr are expected to relate to each other? In particular, is the intention that these eventually converge (e.g., via a redesigned ClangAddressSpaceAttr or the MemorySpaceAttrInterface work), or do we expect them to remain distinct? Understanding the roadmap would help me see the benefit of keeping them separate rather than unifying the representation.

I like the overall direction, thanks for taking the time to improve the holistic approach. One nit is to perhaps rename ClangAdddressSpaceAttr to LangAdddressSpaceAttr. Let's see if other reviewers have more insight here.
(cc @koparasy)

I don’t have a strong objection to the implementation itself — the patch is clear and seems consistent with the upstream direction. My only hesitation is around the conceptual cost of introducing two separate address-space attributes. Address spaces are already a tricky area, and users can also influence them via language-level attributes, so reasoning about them tends to get complicated quickly.

Do we have a long-term plan for how TargetAddressSpaceAttr and ClangAddressSpaceAttr are expected to relate to each other? In particular, is the intention that these eventually converge (e.g., via a redesigned ClangAddressSpaceAttr or the MemorySpaceAttrInterface work), or do we expect them to remain distinct? Understanding the roadmap would help me see the benefit of keeping them separate rather than unifying the representation.

Hey :) thanks for the comment, we initially had laid down support for it to be unified as it is currently down here in the incubator.

The decision to split both attributes came from feedback from one of the mantainers of the core mlir dialects. llvm/llvm-project#161028 (comment) (I'd suggest thoroughly looking at the discussion for full context). Our ultimate goal is to align with other upstream dialects, specifically the ptr dialect and how it attaches memory spaces to it. I think It is fair for both of them to remain distinct in CIR at least. They would converge on the lowering stage as LLVM ir can only represent numeric address spaces.

However, I think @xlauko and @andykaylor have more experience designing dialects and at the end — might have a better answer for you.

The decision to split both attributes came from feedback from one of the mantainers of the core mlir dialects.

Just want to point out that splitting is fine but it shouldn't come with the cost of code readability, having two attributes is super confusing (specially given the names aren't helping here). We should either go for the interface right away (unless there are good reasons to wait a bit more) or rename them a bit (like I suggested in the first comment) + share some of the properties for the sake of clear interfaces (passing the base around).

The decision to split both attributes came from feedback from one of the mantainers of the core mlir dialects.

Just want to point out that splitting is fine but it shouldn't come with the cost of code readability, having two attributes is super confusing (specially given the names aren't helping here). We should either go for the interface right away (unless there are good reasons to wait a bit more) or rename them a bit (like I suggested in the first comment) + share some of the properties for the sake of clear interfaces (passing the base around).

I understand. Got a clear way forward now, thanks a lot for the pointers ^^

Okay, I hope the diff in this patch is not too intimidating :D

I've addressed the naming (Clang -> Lang) and Implemented MemorySpaceAttrInterface as requested. We're no longer generalizing attributes as we used to initially, I think It's much clearer now.

Regarding the implementations of each interface method, I think we can defer this for a later PR. I'm still not sure where these would fit into, I assume we would couple that with the verifiers on top of PointerType, but that's just my guess.

Will fix conflicts once approved.